The Atari Compendium

home *** CD-ROM | disk | FTP | other *** search

/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / prgtools / cli / okami15.lzh / OKAMI15 / DOC / OKAMI.DOC < prev next >

Wrap

Text File | 1992-09-20 | 82.8 KB | 2,169 lines

=============================================== @(#) OKAMI SHELL VERSION 1.4 - BENUTZERANLEITUNG =============================================== Stand: 19.9.1992 BITTE ERST DIE DATEI README LESEN! ---------------------------------------------------------------------------- EINFÜHRUNG Die Okami-Shell (man spricht es "O-Kammi") ist ein (weiterer) Versuch, auf dem Atari ST so etwas wie Unix-Gefühle aufkommen zu lassen. Das Programm wendet sich an alle, die die Möglichkeiten eines Kommandointerpreters denen des Desktops vorziehen. Die Shell ist vor allem beim Betrieb mit einer Festplatte ausgesprochen nützlich. Obwohl es schon einige Programme dieser Art gibt, gibt es gewichtige Gründe, die Okami-Shell zu benutzen und sich durch die folgende Anleitung zu arbeiten. Die Okami-Shell ist einer der Unix-orientierten Kommandointerpreter für den ST, der die Unix-Möglichkeiten der Ein/Ausgabe-Umleitung und des Pipelinings auch für die internen (in der Shell eingebauten) Kommandos ermöglicht. Die Ein/Ausgabe-Umleitung ist die Möglichkeit, die Standard-Ausgabe eines Programmes, d.h. alles, was mit printf, Cconout etc. ausgegeben wird und normalerweise auf dem Bildschirm landet, sowie die Standard-Eingabe in eine Datei oder zu einem Gerät (z.B. zum Drucker) umzuleiten. Die Umleitung funktioniert unter TOS mit dem GEM-Desktop a) nur bei TTP-Programmen, weil man nur bei diesen die Möglichkeit hat, eine Kommandozeile einzugeben, und b) nur bei Programmen, deren Compiler die Umleitung unterstützen. Die Okami-Shell führt die Umleitung selber durch, wodurch auch Programme, die ihre Kommandozeile nicht beachten (z.B. solche, die mit dem Pd-Modula-2-System erstellt wurden), umgeleitet werden können. Die Okami-Shell kann allerdings noch etwas mehr: sie ist ein universelles Utility, mit dem man nicht nur Programme starten, sondern auch Programme schreiben und debuggen usw. kann. Als Bonbon hat sie einen eingebauten UPN-Rechner mit ca. 80 Funktionen sowie einen Terminal-Emulator. Alles in allem bietet die Okami-Shell mehr interne Kommandos und Funktionen als jede andere für den Atari erhältliche Shell. Bei der Programmierung einer Shell oder eines Kommandointerpreters steht man immer vor der Frage, ob man für die in der Shell eingebauten Kommandos Unix-, MS-DOS- oder eine selbstausgedachte Schreibweise benutzen soll, d.h. ob man die Kommandos ls oder dir, mv oder rename, cp oder copy nennen soll oder ob man sich eingene Kommandonamen ausdenkt. Die Okami-Shell ist an den Unix-Bezeichnungen orientiert, genauer gesagt an dem Unix-Derivat AIX, das z.B. auf dem IBM RT PC 6150 läuft. Natürlich müssen bei soetwas Abstriche gemacht werden, der Atari ist schließlich keine Unix-Maschine, und eine Shell ist kein Betriebssystem. Wer sich in Unix einigermaßen auskennt, kann mit der Okami-Shell sofort loslegen. Die folgende Anleitung stellt die Verwendung der Shell dar, die Erklärung der internen Kommandos mit Syntax befindet sich in der Datei commands.doc. Um die vielen Versionen der Shell unterscheiden zu können, gibt das Kommando `ver' eine Information mit Versionsnummer und Kompilierungszeitpunkt aus. Zur Interpretation der Versionsnummer siehe tricks.doc. ---------------------------------------------------------------------------- SUPPORT Die Okami-Shell ist Public Domain, d.h. sie kann von jedermann benutzt und weitergegeben werden, ohne daß jemand etwas dafür zu bezahlen hat. Wer über E-Mail zu erreichen ist, sollte mir über das Maus- oder Usenet eine kleine Nachricht, evtl. mit Kommentaren, Anregungen und Kritik, zukommen lassen. Adresse siehe unten. Über den Support ist es jederzeit und für jeden möglich: 1) die neueste Version der Shell zu bekommen, 2) konfektionierte Versionen zu erhalten, in denen die Systembeschränkungen (Anzahl der Variablen, Funktionen etc.) verändert sind. Wer also eine Version braucht, die bis zu 2000 Variablen verwalten kann, kann eine solche bekommen. Außerdem können beliebige Kommandos ausgeblendet werden, um die Shell kleiner zu machen. Wer also z.B. den UPN-Rechner und das basep-Kommando nicht braucht, kann eine Shell erhalten, in der diese Kommandos nicht enthalten sind und die somit entsprechend kürzer ist. 3) Außerdem ist eine "CLI-Only"-Version erhältlich, die nur die allerwichtigsten Kommandos zur Bedienung der Shell enthält. Diese Version ist ungepackt ca. 63 KB groß (die Vollversion ca. 130 KB) und kann auf Systemen eingesetzt werden, auf denen die wichtigsten Kommandos als externe Programme zur Verfügung stehen. Es ist verboten, die Shell zu verkaufen oder unter einem anderen Namen zu vertreiben. Wer irgendwelche Teile des Programms oder der Quellen in eigenen Programmen benutzen will, darf dies tun, solange mein Name im Programm und in der Dokumentation erwähnt wird. Die Datei `copying' enthält genaue Hinweise zum Kopieren und Weitergeben der Shell. Das Programm wird voll unterstützt, d.h. es wird dynamisch weiterentwickelt, und jeder Anwender kann bei mir jederzeit die neueste Version bestellen. Ebenso stehe ich bei Problemen und Wünschen zur Verfügung. Spenden sind natürlich auch willkommen, aber ausdrücklich nicht Vorraussetzung für den Erwerb von neuen Versionen, Anleitungen oder sonstigen Hilfen (dies ist allen Pd-Programmierern zur Nachahmung empfohlen). Meine Adresse: Wolfram Rösler Augustastr. 44-46 W-5100 Aachen Tel. +49 (0)241 534596 Mausnetz: Wolfram Rösler @ AC2 Usenet: wr@bara.oche.de Bitte bei allen Zuschriften die Versionsnummer und das Kompilierungsdatum der Shell angeben (werden durch Eingabe von "ver" ausgegeben). Bei Fehlermeldungen bitte die Ausgabe von "ver -a" mitschicken. Wer irgendwelche Anregungen für weitere Versionen der Shell hat, kann sich damit jederzeit an mich wenden. ---------------------------------------------------------------------------- PROGRAMMFEHLER "Selbst der umsichtigste Programmierer kommt manchmal in Situationen, wo das Programm nicht richtig funktioniert." Texas Instuments, "Individuelles Programmieren" Handbuch zu TI 58/58C/59, 1977 Der Software-Support deckt die Beseitigung von Fehlern in der Shell ab. Wer einen Fehler findet, sollte also nicht die Okami-Diskette in die Ecke schmeißen und sich einer anderen Shell zuwenden (die hat nämlich auch Fehler), sondern mir einen Hinweis mit möglichst genauer Fehlerbeschreibung schicken. Wenn man eine Diskette und einen frankierten Rückumschlag beilegt, bekommt man die korrigierte Version der Shell sobald wie möglich zurück. Wenn die Shell in Verbindung mit einem anderen Programm Probleme macht, sollte man dieses Programm gleich mitschicken. Bitte bei allen Fehlermeldungen die Ausgabe von "ver -a" mitschicken. Natürlich kann ich keine Verantwortung für irgendwelche Schäden, die durch die Shell, ihre Anwendung oder die Unfähigkeit ihrer Anwendung verursacht werden, übernehmen. Wer also unbedingt df -mn | xargs rm -r {}/* ausprobieren muß, hat das Ergebnis selber auszubaden. ---------------------------------------------------------------------------- LIEFERUMFANG Zur Okami-Shell gehören die folgenden Dateien: KERN: sh.ttp Das Haupt-Shellprogramm. msh.prg Die Microshell zum Starten als GEM-Programm. msh.inf Konfigurationsdatei zur Microshell. profile Konfigurationsdatei beim Start der Shell. help Textdatei mit Syntaxerklärungen. EXTERNE KOMMANDOS: calc.sh Benutzerschnittstelle zum eingebauten UPN-Rechner. format.ttp Programm zum Formatieren von Disketten. gem.prg Programm zur Benutzung von Accessories. gem.rsc Resourcedatei dazu. showpic.sh Demo-Shellscript zur Anzeige von Bilddateien. QUELLEN: msh.c msh.prg gem.c gem.prg format.c format.ttp DOKUMENTATION: readme Grundeinführung für den Anwender. doc\*.* Anleitungen. SONSTIGES: dial.inf Eine Beispieldatei für das dial-Kommando. okami.pic Das Titelbild. okicon.rsc Eine Resourcedatei, die drei Icons mit dem Okami-Logo enthält. _index Indexdatei für `ls -i'. ---------------------------------------------------------------------------- SYSTEMANFORDERUNGEN "Wie der Name unschwer erkennen läßt, besitzt der Atari 520 ST einen enormen Hauptspeicher, nämlich ganze 512 KByte. Der eine oder andere kann sich vielleicht schwer vorstellen, wozu dieser Riesenspeicher benötigt wird." Data Becker, "Das große GEM-Buch" (1985) Die Okami-Shell stellt folgende Anforderungen an das System: Rechner Läuft auf jedem ST-kompatiblen Rechner. Über den Einsatz auf anderen Rechnern mit ST-Emulator liegen noch keine Testergebnisse vor. RAM Die Shell benötigt ca. 200 KB an Laufzeitspeicher => lauffähig auch auf 512KB-Maschinen. Empfohlen werden allerdings 1 MB oder mehr. Massespeicher Für die zum Lauf notwendigen Dateien werden minimal ca. 120 KB benötigt. Mit allen Hilfsdateien (Microshell, Profile,...) werden ca. 200 KB benötigt. Dazu kommen noch die über 300 KB für die Dokumentation. Die Shell kann jedem Massespeicher betrieben werden. Für die Verwendung des Pipelinings ist es jedoch notwendig, daß auf einen Massespeicher (nicht notwendigerweise den, von dem die Shell gestartet wurde) geschrieben werden kann. Für diesen Zweck kann auch eine eigene kleine Ramdisk verwendet werden (16-32K). Bildschirm Läuft in jeder Auflösung. Der Betrieb in niedriger Auflösung ist möglich, aber einige interne Kommandos gehen davon aus, das pro Zeile 80 Zeichen zur Verfügung stehen (z.B. df und hd). Die Benutzung dieser Kommandos kann dann zu Störungen in der Bildschirmausgabe führen. In keinem Fall kommt es jedoch zu einem Programmabsturz. Sollte mit jeder Farb- und Schwarzweiß-Emulation funktionieren. Sollte auch mit allen Großbildschirm arbeiten (ungetestet mangels Großbildschirm). Die Shell unterstützt OverScan (siehe commands.doc zu dem internen Kommando "overscan"). Hardware Die Shell unterstützt Maus, Drucker und die RS232-Schnittstelle sowie ein Modem. Es werden jedoch keine Geräte außer Bildschirm und Tastatur unbedingt benötigt (auch nicht die Maus). (Genaugenommen werden nicht einmal Bildschirm und Tastatur unbedingt benötigt.) Betriebssystem Die Shell wurde unter TOS 1.02 und 1.04 auf einem Atari 1040 ST und Mega ST4 entwickelt und ist "sauber" programmiert, d.h. es erfolgt kein Zugriff auf undokumentierte oder veränderliche Systemadressen o.ä. Die Shell sollte daher mit jedem früheren und zukünftigen TOS zusammenarbeiten. Sie arbeitet mit und unterstützt MiNT. Software Jedes TOS- und TTP-Programm kann von der Shell als externes Kommando aufgerufen werden. GEM-Programme können aufgerufen werden, wenn die Shell selber als GEM-Programm gestartet wird, was z.B. der Fall ist, wenn msh.prg zum Start der Shell benutzt wird. Zum Verändern der Konfigurationsdateien profile und msh.inf ist ein Ascii-Editor erforderlich. ---------------------------------------------------------------------------- INSTALLATION Die Okami-Shell kann direkt von der Diskette gestartet werden. Siehe hierzu den folgenden Abschnitt. Ihre volle Effizienz entwickelt die Shell allerdings erst beim Einsatz von der Ramdisk oder Festplatte. INSTALLATION AUF RAMDISK Ich empfehle die selbstkomprimierende Maxidisk, da sie die optimale Speicher ausnutzung garantiert. Für die Shell sollten mindestens 200 KB Maxidisk oder ca. 300 KB einer anderen Ramdisk zur Verfügung stehen. Für den vollen Betrieb der Shell sollten folgende Dateien (am besten in einen eigenen Ordner) auf die Ramdisk kopiert werden: sh.ttp profile msh.prg msh.inf help okami.pic dial.inf _index in einem Unterordner namens doc: commands.doc <------ aus dem Anleitungsordner in einem Unterordner namens bin: *.sh format.ttp gem.prg gem.rsc ship.exe <------ für Festplattenbenutzer: das ship.prg der Harddisk-Utility-Disk Die Datei help wird für das Shell-Kommando "help" benutzt; wer diese Datei ausdruckt und neben den Rechner legt, kann sich den Platz auf der Ramdisk ebenfalls sparen. Dasselbe gilt für commands.doc, das außerdem ziemlich viel Platz beansprucht. (Auf der Platte - auf dem Papier allerdings auch, außerdem wird commands.doc für die Online-Hilfe benötigt.) Die Dateien msh.prg und msh.inf gehören zusammen und werden zum Start der Shell als GEM-Programm benutzt. Wer von der Shell keine GEM-Programme starten will, braucht diese Dateien nicht. Auf die externen Kommandos wie gem und format kann man natürlich auch verzichten, nur muß man dann u.U. etwas häufiger ins Desktop zurück. Wer kein Modem hat, kann mit dem dial-Kommando nichts anfangen und braucht folglich auch kein dial.inf. Wer nicht bei jedem Systemstart das Titelbild sehen möchte, kann die Datei okami.pic umbenennen oder löschen. Auch auf profile kann man verzichten, allerdings wird die Shell dann mit den eingebauten Voreinstellungen initialisiert. => Die einzige Datei, die man wirklich braucht, ist sh.ttp. INSTALLATION AUF FESTPLATTE Bei der Installation der Shell auf Festplatte kommt echtes Unix-Feeling auf, vor allem wenn man die Shell nach dem Systemstart automatisch starten läßt (ich empfehle zum Autostart: TOS 1.0: den Autostarter aus dem Data Becker-Buch "Die besten Tips&Tricks für Atari ST", S. 24ff. TOS 1.2: den Autostarter "startgem.prg", der zu Superboot 6.0 gehört, siehe PD-Journal 9/90, S. 43ff. >= TOS 1.4: msh.prg im Desktop als Autostart-Applikation anmelden) Mit einigen Tricks, die im folgenden erklärt werden, kann man sich z.B. bei jedem Start der Shell Datum und Uhrzeit des letzten Systemstarts ausgeben lassen oder das aktuelle Arbeitsverzeichnis so einstellen, wie man die Shell zuletzt verlassen hat. Außerdem kann man alle Programme, die man auf der Festplatte hat, per Name starten lassen, egal in welchem Verzeichnis man sich gerade befindet, und es werden sogar alle RSC-Dateien gefunden. Man tippt also z.B. ein: edit datei.txt und es erscheint der Editor mit der Datei datei.txt, egal wo im Dateisystem der Editor sich befindet. Für die Shell sollte ein eigener Ordner eingerichtet werden, in den die oben unter INSTALLATION AUF RAMDISK aufgeführten Dateien kopiert werden. Außerdem ist es sinnvoll, Pipe-Operationen über eine Ramdisk laufen zu lassen. Siehe dazu weiter unten. Wenn man sich die Anleitungen der Shell auf die Festplatte kopiert, braucht man die Datei commands.doc nicht noch einmal in den Shell-Ordner zu kopieren. Dann muß allerdings der Dateiname von commands.doc in der Shell-Variablen HELPFILE gespeichert werden. Siehe dazu weiter unten. INSTALLATION IM AUTO-ORDNER Es ist sehr sinnvoll, ein kleines Programm zu schreiben, das im Auto-Ordner gestartet wird und, wenn eine bestimmte Taste gedrückt ist, die Shell per Pexec ausführt. Wenn dies das erste Programm im Auto-Ordner ist, hat man immer die Gelegenheit, vor dem Start irgendwelcher Programme in die Shell zu gelangen und so z.B. defekte Programme, die das korrekte Hochfahren des Systems verhindern, zu deaktivieren. Die Shell führt keine AES-Aufrufe aus, die beim Start aus dem Auto-Ordner zu Problemen führen würden, da zu dieser Zeit das AES noch nicht initialisiert ist. Die Shell führt AES-Aufrufe erst dann aus, wenn der Anwender sie durch Eingabe des Kommandos `gon' explizit dazu auffordert. Aus diesem Grund ist ein Betreiben der Shell aus dem Auto-Ordner problemlos möglich. INSTALLATION IM COOKIE-JAR Der Cookie-Jar ist eine Möglichkeit des Betriebssystems, mit der installierte Programme dem System ihre Anwesenheit nebst Versionsnummer mitteilen können. Der Cookie-Jar wird erst ab TOS 1.6 vom Betriebssystem selber benutzt, kann aber bei allen früheren TOS-Versionen auch von Programmen installiert werden. Die Okami-Shell trägt sich unter der Kennung "OkSh" in den Cookie-Jar ein. Vorher installiert sie einen solchen, falls noch keiner vorhanden ist. Die Versionsnummer ist auf zwei Bytes aufgeteilt, bei Version 1.5 steht eine 5 im niedrigsten und eine 1 im nächsthöheren Byte. Mit dem internen Kommando `cookie' kann der Cookie-Jar ausgelesen werden. Siehe hierzu commands.doc. Wenn die Shell beendet wird, wird der vorherige Wert wieder als Cookiejar-Adresse eingetragen. Beim Beenden der Shell mit shutdown wird als Cookiejar-Adresse 0 eingetragen. ---------------------------------------------------------------------------- START DER SHELL a) Direkt Die Shell wertet ihre Kommandozeile nach der folgenden Syntax aus: [-] [Flags] [[-- | -c] Cmd [Parameter]] Es bedeuten: - Es wird die Datei profile im aktuellen Directory geladen. Wenn - nicht angegeben ist, wird keine Profile-Datei geladen. (In Unix wird das - als erstes Zeichen von argv[0] übergeben. Das läßt sich in TOS nicht bewerkstelligen, also muß das - in der Kommandozeile stehen.) Flags Beliebige der Flags, die auch für das Kommando set benutzt werden können und das Verhalten der Shell global beeinflussen. Die Flags können also schon in der Kommandozeile eingestellt werden, was nützlich ist, wenn kein Profile benutzt wird. Die Flags können mit + oder - beginnen. Siehe commands.doc für weitere Details. -- Stellt das Ende der Flags dar und signalisiert, daß die weiteren Parameter zu `Cmd' gehören. -- wird nur benötigt, wenn `Cmd' mit einem Minus- oder Pluszeichen beginnt. -c Signalisiert, daß es sich bei `Cmd' um ein auszuführendes Kommando (intern oder extern) handelt. Wenn -c nicht benutzt wird, wird `Cmd' als der Dateiname eines auszuführenden Shellscripts betrachtet. Cmd Ein auszuführendes Kommando oder Shellscript. Wenn Cmd angegeben ist, wird die Shell nach seiner Ausführung beendet. Wenn kein Cmd angegeben ist, wird die Shell interaktiv. Para Optionale Parameter für Cmd. Anmerkung: Über den Software-Support kann eine Shell bezogen werden, die sich im Hinblick auf das übergebene Minuszeichen genau andersherum verhält, d.h. sie initialisiert sich mit dem Profile immer, außer es wird ein Minuszeichen übergeben. Beispiele: sh Die Shell wird interaktiv gestartet. Es wird kein Profile geladen. sh - Die Shell wird interaktiv gestartet. Die Datei profile im aktuellen Directory oder (falls gesetzt) die in der Environment-Variablen OKSH_PROFILE angegebene Datei wird geladen. Dies ist der normale Start der Shell. sh - -i Die Shell wird interaktiv gestartet, die Datei profile wird geladen, und es wird der Insert-Modus des Zeileneditors abgeschaltet (-i). sh myscript Die Datei myscript wird als Shellscript ausgeführt, danach wird die Shell beendet. sh -x myscript Die Datei myscript wird als Shellscript ausgeführt, danach wird die Shell beendet. Vorher wird das Flag x gelöscht, wodurch die Shell beim Start von Binärprogrammen das aktuelle Verzeichnis nicht auf das Verzeichnis einstellt, in dem die Programmdatei enthalten ist. sh -L <myscript Das Flag L wird gelöscht, wodurch die Shell Kommandos von der Standardeingabe (statt mit dem Zeileneditor von der Tastatur) einliest. Dadurch wird die Datei myscript ausgeführt. Diese Art des Startens eines Shellscripts unterscheidet sich nur geringfügig von dem direkten Angeben des Shellscripts und kann z.B. benutzt werden, um Kommandos von einer Pipeline oder einer Schnittstelle auszuführen. sh -c ver Die Shell führt das Kommando `ver' aus und terminiert. b) Indirekt Die Shell kann indirekt von jedem Programm aus mit der GEMDOS-Funktion Pexec gestartet werden. Dies geschieht z.B. beim Aufruf von der Microshell. Da die Shell den Environment-String benutzt, sollten Programme, die das nicht tun, als letzten Parameter von Pexec eine (long)0 übergeben (und nicht einen Leerstring). Wenn der Shell dabei ein Parameterstring übergeben wird, so wird dieser wie oben beschrieben ausgeführt. Der Parameterstring kann der Shell auch nach dem xArg- oder ARGV-Verfahren übergeben werden. Wenn die Shell als Login-Shell gestartet werden soll und es möglich sein soll, GEM-Programme von der Shell aus zu starten, muß die Shell mit der Microshell (msh.prg) gestartet werden. Dazu müssen folgende Voraussetzungen zutreffen: 1) Im selben Directory wie sh.ttp stehen die Dateien msh.prg und msh.inf. 2) Die Datei msh.inf enthält mindestens die folgende Zeile: sh.ttp - Dann wird die Shell nach Doppelklick auf msh.prg automatisch als Login-Shell gestartet. Es können alle GEM-Programme von der Shell aus ausgeführt werden. Siehe hierzu auch msh.doc. Wenn die Shell auf diese Weise vom Desktop aus gestartet wird, sollte das Profile die Zeile trap cursor -v enthalten. Dann wird nach dem Ende der Shell automatisch der Cursor abge schaltet (auf dem Desktop stört er ziemlich). Siehe hierzu auch commands.doc. c) Über den Shellpointer (_shell_p) Der Shellpointer befindet sich in Adresse 0x4F6 und enthält einen Zeiger auf eine Funktion, die ein ihr übergebenes Kommando ausführt. Auf diese Weise ist es möglich, aus einem von der Shell gestarteten Programm aus Shellkommandos auszuführen, ohne daß die Shell nochmal geladen werden muß. Ein Beispiel für die Verwendung ist das mitgelieferte gem.prg. Die Funktion, deren Adresse in 0x4F6 hinterlegt wird, hat folgende Syntax: int Fct(char *cmd) `cmd' ist ein String mit dem auszuführenden Kommando. Dies kann ein beliebiges Shell-Kommando sein. Mehrere Kommandos können durch `;' verkettet werden. Wenn ein leerer String oder ein NULL-Zeiger übergeben wird, arbeitet die Shell im Dialogmodus, ansonsten wird nur cmd ausgeführt. Zurückgegeben wird der Rückgabewert des Kommandos. Achtung: Bei dieser Art des Aufrufes wird die bereits laufende Shell ausgeführt. Das bedeutet, daß alle Shellvariablen und Shellfunktionen der laufenden Shell benutzt und verändert werden können. Die vollständige Reentranz der Shell kann jedoch nicht garantiert werden. Insbesondere sollten mit einer auf diese Weise gestarteten interaktiven Shell keine externen Programme aufge rufen werden. (was allerdings teilweise möglich ist und offenbar von dem betreffenden Programm abhängt.) --------------------------------------------------------------------------- KONFIGURATION Wenn der Shell als einziger Parameter ein Minuszeichen übergeben wird, sucht sie nach dem Start im aktuellen Verzeichnis eine Datei mit dem Namen profile. Wenn die Environment-Variable OKSH_PROFILE gesetzt ist, wird stattdessen die in dieser Variable angegebene Datei benutzt. Wenn diese Datei vorhanden ist, wird sie wie ein Shellscript (siehe dazu weiter unten) ausgeführt. Das Profile kann eine Einschaltmeldung auf dem Bildschirm ausgeben und Shellvariablen wie z.B. das Prompt (PS1) setzen. Außerdem können die Shell-Flags eingestellt werden (siehe dazu das in- terne Kommando `set' in commands.doc). Das Profile kann alle Aktionen ausführen, die ein normales Shellscript auch ausführen kann. Siehe hierzu auch tricks.doc. ---------------------------------------------------------------------------- KOMMANDOEINGABE a) Von der Tastatur Wenn die Shell im Dialogmodus gestartet ist, können nach dem Prompt (i.d.R. ein Dollarzeichen) Kommandos eingegeben werden. (Das mitgelieferte Profile stellt das Prompt um, so daß im Prompt immer das augenblickliche aktuelle Directory zu sehen ist.) Mit dem internen Kommando keydef kann jede beliebige Taste umdefiniert werden. Das bedeutet, daß alle der unten angeführten Tastenfunktionen ungültig werden können, wenn die jeweiligen Tasten umdefiniert werden. Die einzigen Funktionen, die nicht umdefiniert werden können, sind ENTER und Ctrl Shift Undo. Für weitere Informationen siehe commands.doc zum Thema keydef. Bei der Eingabe werden folgende Sondertasten benutzt: Backspace bewegt den Cursor nach links und löscht das dort stehende Zeichen. Pfeil auf Es wird das zuletzt eingegebene Kommando angezeigt. Dieses kann mit ENTER übernommen oder mit Backspace editiert werden. Durch wiederholten Druck auf Pfeil auf wird das vorletzte Kommando angezeigt usw. Es werden maximal 100 Kommandos gespeichert (wer mehr braucht, benutze den Software-Support, um eine entsprechend angepaßte Version der Shell zu erhalten.) Diese Eigenschaft der Eingabe nennt man "History". Shift Pfeil auf Wie Pfeil auf, aber es wird die letzte Zeile aus der History angezeigt, die mit der bisherigen Eingabe übereinstimmt. Gibt man also ein "ls " und drückt Shift Pfeil auf, dann wird das letzte ls-Kommando zurückgeholt. Der Zeiger in der History-Liste steht dann hinter dieser Zeile, ein weiterer Druck auf Shift Pfeil Auf bringt also das vorletzte ls-Kommando zurück usw. Ctrl Pfeil auf Wie Pfeil auf gefolgt von einem Druck auf ENTER, es wird also das zuletzt eingegebene Kommando nicht nur angezeigt, sondern auch ausgeführt. Geht auch zusammen mit Shift. Pfeil ab Zeigt das nächste Kommando in der History-Liste an. Mit Pfeil auf und Pfeil ab kann man also in den in der History-Liste gespeicherten Kommandos blättern. Shift Pfeil ab Analog zu Shift Pfeil auf. Ctrl Pfeil ab Wie Pfeil ab gefolgt von einem Druck auf ENTER, analog zu Ctrl Pfeil auf. Shift Esc Dateinamen-Vervollständigung für alle Dateien, die auf ein Suchmuster passen. Siehe unten. Esc Dateinamen-Vervollständigung für eine Datei. Siehe unten. Pfeil links/rechts bewegen den Cursor: mit Shift zum Zeilenanfang/ende, mit Control jeweils ein Wort nach links/rechts, sonst jeweils ein Zeichen nach links/rechts. Delete mit Control: löscht die Zeile von der Cursorposition bis zum Zeilenende. Sonst: löscht das Zeichen unter dem Cursor. Shift Space Speichert die aktuelle Position für Pfeil rechts. Siehe unten. Clr-Home Die Eingabezeile wird gelöscht. Help Es wird eine Erklärung des eingegebenen Kommandos ausgegeben. Siehe unten. Ctrl Shift Undo Für diese Eingabezeile wird die Tasten-Redefinition ausgeschaltet. Die Eingabe verhält sich also so, als ob seit dem Start der Shell keine keydef-Kommandos ausgeführt worden wären. Die Funktion wird durch ein Klingelzeichen bestätigt. Control V Das nächste eingegebene Zeichen wird nicht als Steuerzeichen interpretiert. Auf diese Weise kann man z.B. VT52-Sequenzen eingeben: echo <ESC>E geht nicht, da das ESC interpretiert wird (und Filename-Completion einleitet), man muß es so eingeben: echo <Ctrl-V><ESC>E Control F Es erscheint eine Fileselect-Box, der ausgewählte Dateiname wird in die Eingabe übernommen. Das geht nur, wenn gon aktiv ist (siehe commands.doc zum Stichwort gon). Control P Es wird eine Hardcopy ausgeführt. Dies geschieht durch Aufruf der Shellfunktion "screensave". Die Voreinstellung dieser Funktion ist ein einfacher Aufruf des internen Kommandos "hardcopy", wodurch der Bildschirminhalt auf dem Drucker ausgegeben wird. In der Datei `tricks.doc' ist eine screensave-Funktion angegeben, durch die die Hardcopy in eine Datei geschrieben wird. Control A Der Bildschirm wird dunkelgeschaltet. Nach Druck auf eine der Shifttasten, Control oder Alternate kann man weiterarbeiten. (Um diese Funktion zu benutzen, sollte gon aktiv sein, da sie dann VDI-Funktionen benutzen kann; wenn gon nicht aktiv ist, schreibt sie direkt in den Bildschirmspeicher, was bei Großbildschirm usw. nicht funktioniert.) Alternate Space Es werden Uhrzeit und Datum angezeigt, bis die Alternate-Taste losgelassen wird. Control D Die Shell wird beendet. Es können beliebige Ascii-Codes in der Schreibweise `^ooo' eingegeben werden, wobei ooo eine dreistellige Oktalzahl ist. Um z.B. Klingelzeichen in eine Eingabe einzubauen: echo "Jetzt kommt eine Klingel: ^007" Auf diese Weise können alle VT52-Sequenzen benutzt werden. Siehe auch `echo' in commands.doc. Dateinamen-Vervollständigung (Filename-Completion): Die Shell bietet die Möglichkeit, nur einen Teil eines Dateinamens einzugeben und diesen dann zu dem vollen Dateinamen expandieren zu lassen. Dazu gibt es zwei Möglichkeiten: 1) Nach Druck auf Taste Shift-Escape wird das zuletzt eingegebene Wort zu allen Dateinamen expandiert, die nach den Regeln der erweiterten Wildcards auf dieses Wort passen. Beispiel: $ cat *.c<SHIFT ESC> erzeugt $ cat sh.c cmds.c utl.c ... 2) Nach Druck auf die Taste ESC kann der Anwender aus den auf das letzte Wort passenden Dateien eine auswählen. Wenn nur eine Datei paßt, wird diese direkt übernommen, ansonsten kann eine Datei mit folgenden Tasten ausgewählt werden: Pfeil links/rechts die jeweils nächste/vorige Datei. Pfeil auf/ab zum Anfang/Ende der Liste. Leertaste Dateilänge und Anzahl der passenden Dateien wer den ausgegeben. Hierbei bedeutet `4/10' die vierte Datei von insgesamt zehn. Return der gerade angezeigte Dateiname wird übernommen. ESC die Auswahl wird abgebrochen, die bisherige Eingabe bleibt unverändert. Clr-Home die Auswahl wird abgebrochen, das Suchmuster wird aus der Eingabe entfernt. Help eine Tastenübersicht wird angezeigt. Sowohl für Pfeil links als auch für ESC gilt, daß die Funktion des eingegebenen Wortes mit dem Shell-Flag f verändert werden kann. Wenn dieses Flag gesetzt ist (set +f), dann stellt das eingegebene Wort ein Präfix dar, z.B. steht `abc' dann für alle Dateien, deren Name mit abc anfängt. Wenn das Flag f nicht gesetzt ist (set -f), steht das eingegebene Wort nur für die Dateien, die (nach den Regeln für erweiterte Wildcards) auf dieses Wort passen, `abc' steht dann also nur für die Datei abc. Zur Verwendung der Help-Taste: Mit der Help-Taste kann jederzeit, und zwar ohne die Eingabe zu stören, zu einem Kommando die entsprechende Anleitung aus der Datei `commands.doc' oder einer anderen Hilfsdatei angezeigt werden. Will man z.B. eine Diskette formatieren, so tippt man das Kommando "format" ein und überlegt dann, wie die Parameter noch waren - dann hilft ein Druck auf Help, und es erscheint die Anleitung zu format. Anschließend kann die Eingabe fortgesetzt werden. Das funktioniert auch, wenn bereits Parameter nach format eingegeben worden sind. Wenn man die Help-Taste bei leerer Kommandozeile drückt, wird man nach dem zu erklärenden Kommando gefragt. Bei der Angabe des zu erklärenden Kommandos gelten die Regeln für erweiterte Wildcards, d.h. mit "r*" wird das erste Kommando erklärt, das mit r beginnt usw. Beispiel: $ format A: <HELP> Eingabe format - Formatieren von Disketten Ausgabe ..... (usw.) $ format A: * weiter gehts (In diesem Beispiel steht <HELP> für das Drücken der Help-Taste und * für die Cursor-Position am Ende. $ ist das Shell-Prompt.) Der Pfadname der Datei commands.doc muß in der Shell-Variablen HELPFILE gespeichert sein. Die Voreinstellung ist $HOME\doc\commands.doc. Wenn die Variable HELPFILE nicht gesetzt ist, wird die Datei help.txt im aktuellen Directory benutzt. Wenn das Stichwort in der in HELPFILE angegebenen Hilfsdatei nicht gefunden wird, sucht die Shell nach einer Datei folgenden Namens: pfad\name.ext `pfad' ist einer der in der Shell-Variablen MANPATH angegebenen Pfade, und `ext' ist einer der in der Shell-Variablen MANEXT angegebenen Extender. `name' ist das eingegebene Stichwort. Das Suchen der Datei erfolgt analog zum Suchen einer Programmdatei mit den Variablen PATH und SEXT/XEXT. Beispiel: MANPATH=$HOME/doc, MANEXT=.doc, Eingabe: lharc. Dann sucht die Shell nach einer Datei namens $HOME/doc/lharc.doc. Die Datei wird, falls gefunden, mit den eingebauten Kommando pg angezeigt. Um möglichst schnellen Zugriff auf die Hilfsdatei zu ermöglichen, erstellt die Shell nach dem Laden einen Index, in dem die einzelnen, in der Datei enthaltenen Kommandos verzeichnet sind. Dieser Index wird nach der Erstellung in eine Datei abgespeichert, die denselben Pfad und Dateinamen wie die Hilfsdatei, aber den Extender .idx hat (z.B. commands.idx). Beim nächsten Laden der Hilfsdatei wird der Index aus dieser Datei geladen, was besonders bei Festplatten eine enorme Beschleunigung gegenüber dem Neuerstellen des Index im Speicher darstellt. Wenn die Hilfsdatei neuer ist als die Indexdatei, wird ebenfalls ein neuer Index erstellt und abgespeichert. Dadurch wird erreicht, daß die Indexdatei immer zu der Hilfsdatei paßt, auch wenn letztere verändert wird. Wenn man eine neue Indexdatei erstellen will, genügt es, die alte Indexdatei zu löschen. Die Verwendung einer Indexdatei kann mit dem Shell-Flag -H unterbunden werden. Dies ist wichtig für Diskettenbenutzer, bei denen das Laden der Indexdatei länger dauert als die Neuerstellung des Index im Speicher. Siehe hierzu commands.doc zum Thema `set'. Anstelle von commands.doc kann auch jede andere Datei als Hilfsdatei benutzt werden. Damit ein Kommando in der Datei erkannt wird, muß die Datei folgende Regeln erfüllen: 1) Vor dem Text, der das Kommando erklärt bzw. der zu dem Kommando ausgegeben werden soll, muß eine Zeile stehen, die mit fünf Minuszeichen beginnt. 2) Direkt nach dieser Zeile muß eine Zeile stehen, die mit dem Kommando beginnt. Das Kommando geht vom Anfang der Zeile bis (exkl.) zum ersten Nicht-Buchstaben (Buchstaben sind a-z und A-Z, keine Umlaute, kein ß) und darf maximal 10 Zeichen lang sein. Danach können weitere Informationen stehen, die nicht beachtet werden. 3) Der auszugebene Text beginnt mit der unter 2) beschriebenen Zeile und geht bis zur nächsten Zeile, die mit fünf Minuszeichen beginnt (exkl.). Beispiel: ----- 1) ls - Anzeigen von Directories 2) 3) (Weitere Angaben) 4) 5) ----- 6) Bei der Eingabe von "ls <HELP>" werden die Zeilen 2) bis 5) ausgegeben. Natürlich kann man auch eine Kopie von commands.doc anfertigen und dort einige weitere beliebige Informationen eintragen, die unter entsprechenden Stichworten abgefragt werden können. Die Ausgabe erfolgt wie mit dem Kommando "pg". Siehe hierzu commands.doc. TECHNISCHER HINWEIS Wenn die Hilfsdatei im Speicher steht und von der Shell aus ein anderes Programm gestartet wird, übergibt die Shell diesem in der Environment-Variablen _HELP_ADR die Adresse eines Pointers auf die geladene Hilfsdatei. Auf diese Weise kann eine Subshell auf die bereits geladene Datei zugreifen, ohne diese selber laden zu müssen (was einen nicht unerheblichen Aufwand an Speicherplatz bedeuten würde.) Die Shell liest den Inhalt von _HELP_ADR direkt nach der Initialisierung der Variablen aus dem Environment und löscht danach die Shellvariable _HELP_ADR. Beim Aufruf weiterer Programme wird diese Variable nur während der Erstellung des Environments für das neue Programm angelegt. Die Variable _HELP_ADR ist also für den Anwender der Shell niemals sichtbar, befindet sich aber im Environment aller gestarteten Programme. Für die Übergabe ist es notwendig, daß noch mindestens ein Platz in der Variablentabelle frei ist. Das Format von _HELP_ADR ist 0xAAAAA:0xBBBBB , wobei AAAAA die Adresse eines Pointers ist (hexadezimal). Dieser Pointer zeigt auf den Text der geladenen Datei. 0xBBBBB ist die Adresse einer internen Indextabelle, die die Shell zum schnellen Zugriff auf die geladenen Daten benutzt. Diese Indextabelle ist ein Array von Strukturen des Typs struct { char Name[12]; long Offset; } HelpIdxTyp; `Name' ist der Name eines Kommandos und `Offset' ist die Byte-Entfernung der Erklärung dieses Kommandos von dem Beginn des Textes (der durch den Zeiger in der Adresse 0xAAAAA angegeben wird). Das Ende dieser Tabelle ist durch einen Eintrag mit Offset=-1L markiert. Die angelegte Indexdatei stellt ebendiesen Array dar. (0xAAAAA ist also vom Typ (char **), während 0xBBBBB vom Typ (HelpIdxTyp*) ist.) ACHTUNG: auf keinen Fall darf der Pointer verändert werden. b) Von der Standardeingabe Wenn das Flag L nicht gesetzt ist, ist der Zeileneditor ausgeschaltet, und die Shell liest Kommandos von der Standardeingabe. Das bedeutet, daß weder die Editierfunktionen noch die sonstigen Funktionen des Zeileneditors, wie Filename Completion, Fileselect-Box, Help-Taste usw. zur Verfügung stehen. Der Sinn dieses Modus ist, Kommandos von etwas anderem als der Tastatur, z.B. von einer Schnittstelle, einer Datei oder einer Pipe, einzulesen. Um den Zeileneditor schon beim Start der Shell auszuschalten, muß beim Start von sh.ttp das Flag -L angegeben werden. Innerhalb der Shell kann dieselbe Wirkung durch Eingabe von "set -L" erreicht werden. Mit "set +L" wird der Zeileneditor wieder eingeschaltet. Wenn der Zeileneditor abgeschaltet ist, kann die Shell nur durch Eingabe von "exit" oder durch Druck auf Ctrl-Z beendet werden. c) Aus einer Datei Es ist möglich, Dateien zu schreiben, die Shell-Kommandos enthalten und diese Dateien Kommando für Kommando von der Shell ausführen zu lassen. Solche Dateien werden als Shell-Scripts (oder in der MS-DOS-Welt als Batch-Dateien) bezeichnet. Ein Shell-Script kann wiederum weitere Scripts ausführen usw., wobei die Tiefe der Schachtelung durch den zur Verfügung stehenden Speicher begrenzt ist. Rekursive Shellscripts sind natürlich auch möglich. Für die Kommandos in Shell-Scripts gelten dieselben Regeln wie für Kommandos, die über die Tastatur eingegeben werden. Wenn MiNT installiert und das Shell-Flag -r gesetzt ist, dann führt die Shell jedes Shellscript in einer Subshell aus, d.h. die Shell kopiert sich selber, und die Kopie führt das Shellscript aus. Das hat den Vorteil, das Scripts set-Einstellungen, Variablen usw. ändern können, ohne diese nachher wiederherstellen zu müssen. Wer wenig Speicher hat, sollte auf diese Möglichkeit allerdings besser verzichten. Da das Script in einer Kopie der aktuellen Shell ausgeführt ist, findet es dieselbe Arbeitsumgebung wie diese Shell, d.h. insbesondere alle Shellvariablen, auch wenn diese nicht exportiert sind. Ohne MiNT oder wenn das Shell-Flag -r nicht gesetzt ist führt die Shell alle Shellscripts selber aus. Das bedeutet, daß das Script Variablen und sonstige Einstellungen in der ausführenden Shell verändern kann. Bei der Ausführung eines Shellscripts wird das Script erst vollständig in den Speicher geladen und dann im Speicher ausgeführt. Das liefert besonders bei der Ausführung von Diskette enorme Geschwindigkeitsvorteile. Bei Shellscripts gibt es die Möglichkeit, Programmierstrukturen wie if und while zu benutzen, die bei Tastatureingabe wenig Sinn machen. Damit ist es in der Tat möglich, Shellscripts zu schreiben, die wie ein Programm einer höheren Programmiersprache laufen. Siehe hierzu showpic.sh und commands.doc. Es gibt vier Arten von Kommandos: 1) interne Kommandos, 2) externe Kommandos, 3) Shellfunktionen, 4) Kommentare. INTERNE KOMMANDOS Ein internes Kommando ist ein Kommando, durch das eine Funktion innerhalb der Shell ausgeführt wird, das also in der Shell eingebaut ist. Interne Kommandos werden durch Eingabe ihres Namens aufgerufen. Genaue Erklärungen aller interner Kommandos befinden sich in der Datei commands.doc. EXTERNE KOMMANDOS Ein externes Kommando ist nicht in der Shell eingebaut, sondern in einer Datei auf einer Diskette, Ramdisk oder Festplatte vorhanden. Hierbei kann es sich sowohl um eine ausführbare Datei (.PRG, .TOS etc.) als auch um ein Shellscript handeln. Externe Kommandos können durch Eingabe des vollständigen Pfadnamens der entsprechenden Datei, aber auch durch Eingabe des Kommandonamens (des Dateinamens ohne Pfad und Extender) gestartet werden. Die zugehörige Datei wird auf den Pfaden gesucht, die in der Shell-Variablen PATH gespeichert sind. Mit dem hash-Kommando kann der Pfad eines Kommandos der Shell mitgeteilt werden, ohne daß er in $PATH enthalten ist. Externe Kommandos können nur ausgeführt werden, wenn ihr Datei-Extender einem der in den Shell-Variablen XEXT und SEXT gespeicherten entspricht. (Es kann jedoch jede Datei, unabhängig vom Dateinamen, explizit als Shellscript oder Binärdatei ausgeführt werden, und zwar mit den Kommandos `.' und `exec'.) Siehe hierzu auch den Abschnitt über externe Kommandos in commands.doc. Externen Programmen werden die Parameter nach dem xArg-Verfahren übergeben, wenn das Shell-Flag `a' gesetzt ist (siehe commands.doc zum Thema `set'). Dies ermöglicht die Übergabe von beliebig vielen Parametern, während Gemdos die Parameter auf 125 Zeichen beschränkt. Achtung: einige (wenige) Programme vertragen sich damit nicht und laufen nur, wenn die xArg-Übergabe mit `set -a' unterbunden wird. Dazu gehört z.B. der Entpacker `unzip'. Wenn der Aufruf eines externen Kommandos von einem `&' gefolgt ist, z.B. c:/mint/getty.ttp u:/dev/tty1 & , dann wird das Programm als Hintergrundprozeß gestartet, die Shell läuft also weiter, während das Programm läuft. Die Prozeßnummer des Hintergrundprozesses wird auf dem Bildschirm ausgegeben. Die Standardausgabe des Programmes wird dadurch nicht umgeleitet, d.h. wenn ein Hintergrundprozeß Ausgaben macht, dann erscheinen diese ebenfalls auf dem Bildschirm und vermischen sich ggfs. mit denen der Shell. Daher sollte beim Aufruf eines Hintergrundprozesses immer die Ausgabe umgeleitet werden, notfalls nach NULL: (oder u:/dev/null). SHELLFUNKTIONEN Shellfunktionen sind Shellscripts, die resident im Speicher gehalten werden. Sie haben dieselben Eigenschaften wie Shellscripts und können deshalb auch genauso programmiert werden. Alles, was über die Verwendung von Shellscripts gesagt wird, gilt auch für Shellfunktionen. Jede Shellfunktion hat einen Namen, der bis zu 80 Zeichen lang sein darf. Groß- und Kleinschreibung wird unterschieden, d.h. "hallo" und "Hallo" sind zwei verschiedene Shellfunktionen. Bei der Ausführung haben Funktionen die oberste Priorität, kommen also noch vor den internen Kommandos. Es ist also möglich, interne Kommandos umzudefinieren, indem man eine Shellfunktion mit demselben Namen anlegt. Innerhalb dieser Funktion kann auf das ursprüngliche Kommando zugegriffen werden, indem man dem Kommando ein Ausrufezeichen (ohne Leerzeichen) vorstellt. Die Syntax einer Deklaration von Shellfunktionen ist: [Funktionsname] "(" Dateiname ")" (1) oder Funktionsname "()" (2) "{" {Zeilen des Funktionsrumpfes} "}" oder Funktionsname "()" (3) "{}" (1) In der ersten Fassung wird die angegebene Datei als Shellscript in den Speicher geladen und unter dem Namen der Funktion abgespeichert. Wenn kein Funktionsname angegeben ist, wird der Basisname des Dateinamens (ohne Extender) als Funktionsname benutzt. In dieser Fassung entspricht die Shellfunktion also einem speicherresidenten Shellscript. Wenn die angegebene Datei eine ausführbare Programmdatei ist, wenn also ihr erstes Wort 0x601a ist, wird das Programm geladen und eine Shellfunktion erzeugt, die das Programm mit `exec -x' startet. Auf diese Weise ist es möglich, auch Binärprogramme resident im Speicher zu halten und ohne Disketten- oder Plattenzugriffe beliebig oft zu starten. ACHTUNG: Die Vorgehensweise dabei beruht auf der Fähigkeit der Gemdos-Funktion Pexec, Binärprogramme zu laden und erst zu einem späteren Zeitpunkt unter Angabe der Basepage-Adresse zu starten. Die Dokumentation von Atari zu diesem Feature ist kurz und eindeutig; sie lautet: "Finger davon". Nichtsdestoweniger funktioniert es, aber es besteht keine Garantie, daß es immer oder mit allen Programmen oder Betriebssystemversionen funktioniert. (2) In der zweiten Fassung wird die Funktion von der Tastatur oder dem Shellscript, in dem die Deklaration steht, gelesen. Wenn bereits eine Funktion mit dem angegebenen Namen existiert, wird sie umdefiniert. Wenn der Funktionsrumpf leer ist, wenn also die Zeilen mit `{' und `}' direkt aufeinander folgen, wird die Funktion gelöscht. In dieser Fassung wird die Eingabe verkürzt, d.h. Leerzeilen, Kommentarzeilen und führende Leerzeichen werden nicht mit abgespeichert. (3) In der dritten Fassung wird die Funktion gelöscht. Das geht auch mit dem Kommando `unset Funktionsname'. Die zweite und dritte Fassung erwarten also mehr als eine Zeile. Die weiteren Zeilen der Deklaration werden von der sog. "Sekundäreingabe" erwartet, also von dem Gerät oder der Datei, von der augenblicklich Kommandos gelesen werden (das ist nicht immer die Standardeingabe). Wenn es sich dabei um die Tastatur handelt, erscheint als Prompt der Inhalt der Shellvariablen PS2. ACHTUNG: In keinem Fall darf zwischen Funktionsname und der geöffneten Klammer ein Leerzeichen stehen. Beispiele: hallo(hallo.sh) initialisiert eine Funktion namens "hallo". Die Funktion entspricht dem Shellscript hallo.sh. hallo (hallo.sh) ruft das Kommando hallo mit dem Parameter (hallo.sh) auf, ist also KEINE Deklaration einer Shellfunktion. (Schuld daran ist das Leerzeichen nach "hallo".) (c:/bin/test.sh) initialisiert eine Funktion aus der Datei c:/bin/test.sh. Da kein Funktionsname angegeben ist, wird der Basisname der Datei benutzt, es wird also die Shellfunktion "test" erzeugt. (Nebenbei bemerkt: dadurch wird das interne Kommando "test" umdefiniert.) (c:/bin/hallo.prg) lädt das Programm hallo.prg und erzeugt eine Shellfunktion namens hallo, die das geladene Programm startet. hallo hat dabei folgenden Funktionsrumpf: exec -lg c:/bin/hallo.prg 0xnnnn wobei nnnn die beim Laden ermittelte Adresse der Basepage von hallo.prg ist (hexadezimal). hallo() { echo Hallo, wie gehts? read _ echo Es freut mich, daß es Dir $_ geht. unset _ } definiert die Funktion `hallo' mit dem angegebenen Funktionsrumpf. Die Verwendung von Shellvariablen ist möglich; in diesem Fall wird die Variable _ (Underscore) benutzt, die für temporäre Verwendungen zur Verfügung steht. Diese Deklaration kann sowohl in einem Shellscript stehen als auch über die Tastatur eingegeben werden. Bei Tastatureingabe erscheint das Prompt $PS2. ls() { !ls -C $* } Das interne Kommando ls wird so umdefiniert, daß die Option -C immer aktiv ist. Dies geschieht durch Definition einer Shellfunktion mit Namen ls, die das interne Kommando durch !ls aufruft. alias ls !ls -C hat dieselbe Wirkung. hallo() {} Die Shellfunktion hallo wird gelöscht. hallo() { } Dito. unset hallo Dito. () (weder Funktions- noch Dateiname angegeben) ist ein Syntaxfehler. Mit dem internen Kommando "fcts" kann eine Liste sämtlicher Shellfunktionen erzeugt werden. Die Definition einer beliebigen Shellfunktion kann mit dem Kommando "type" ausgegeben werden. Siehe hierzu commands.doc. Es gehört zur Philosophie von Unix, daß man an der reinen Eingabe nicht erkennen kann, ob es sich bei dem eingegebenen Kommando um ein internes Kommando, eine ausführbare Datei, ein Shellscript oder eine Shellfunktion handelt. Um das herauszufinden, gibt es das interne Kommando `type'. Siehe hierzu commands.doc. KOMMENTARE Eine Eingabe gilt als Kommentar, wenn sie mit einem Doppelkreuz (#) beginnt oder wenn sie nur aus einer leeren Zeile besteht. Kommentare werden von der Shell nicht weiter beachtet und sind nützlich zum Dokumentieren von Shellscripts. Die Tastatureingabe von Kommentaren ist zwar möglich, aber nicht unbedingt sinnvoll. --------------------------------------------------------------------- ERWEITERTE WILDCARDS Die Okami-Shell erlaubt für die Angabe von Dateinamen ein Wildcard-System, das weit über das von Gemdos gestellte hinausgeht. Die einzigen Gemdos-Wildcards sind * und ?, wobei ein ein Dateiname nur einen Stern enthalten darf, und den nur am Ende von Name oder Extender. Bei "**" gibt es Probleme, "*hallo*" liefert nicht alle Dateinamen, die "hallo" enthalten usw. Die erweiterten Wildcards der Okami-Shell orientieren sich an denen, die von der Original-Unix-Shell zur Verfügung gestellt werden. Es bedeuten: * beliebig viele, auch null, beliebige Zeichen. ? genau ein beliebiges Zeichen. [abcd] genau ein Zeichen, und zwar eins der in den Klammern ste- henden. Es dürfen beliebig viele Zeichen angeführt sein. [a-g] genau ein Zeichen, und zwar a, b, ... oder g. Das Minuszei- chen bedeutet also "bis". [~abc] genau ein Zeichen, und zwar ein beliebiges bis auf die Zei- chen in den eckigen Klammern. Es dürfen beliebig viele Zei- chen angeführt sein. Der Punkt zwischen Dateiname und Extender wird dabei wie jedes andere Zeichen behandelt, "*" paßt also auf alle Dateinamen und nicht nur auf die ohne Extender. Beispiele: * alle Dateinamen. *.* alle Dateinamen, die einen Extender haben. *.? alle Dateinamen, deren Extender aus genau einem Zei- chen besteht. *.[co] alle Dateinamen mit Extender .c oder .o. *.[~co] alle Dateinamen außer denen mit Extender .c und .o. [abcd]*[xyz] alle Dateinamen, deren erstes Zeichen a, b, c oder d und deren letztes Zeichen x, y oder z ist. Der Punkt, der den Extender einleitet (falls vorhanden), kann irgendwo dazwischen stehen. a[0-9] alle Dateinamen, die aus a, gefolgt von einer Ziffer be- stehen, also a0, a1, ..., a9. ??[a-z][0-9] alle Dateinamen, die aus zwei beliebigen Zeichen, gefolgt von einem Buchstaben und einer Ziffer bestehen. Wenn das Shell-Flag w nicht gesetzt ist, sind die erweiterten Wildcards außer Kraft gesetzt. Die Shell benutzt dann nur die Wildcards, die von TOS zur Verfügung gestellt werden. Das Programm für den Vergleich mit erweiterten Wildcards stammt von Rich Salz und wurde 1986 geschrieben. --------------------------------------------------------------------------- FLAGS UND PARAMETER Jedem Kommando können Flags und Parameter übergeben werden. I.d.R. werden Parameter benutzt, um festzulegen, womit etwas getan werden soll, und die Flags legen fest, wie es getan werden soll. Die Shell teilt die Eingabezeile in Worte auf. Worte werden durch White- space-Zeichen (Leerzeichen, Tab, Formfeed) getrennt. Durch doppelte (") oder einfache (') Anführungszeichen können auch Whitespace-Zeichen in Worten benutzt werden, z.B. ist a b c d vier Worte, während "a b c d" nur ein Wort ist. Einfache Anführungszeichen verhindern außerdem jede Art von Interpretation, d.h. innerhalb von einfachen Anführungszeichen werden * keine Shellvariablen expandiert * keine Slashes zu Backslash umgeformt * keine Escape-Sequenzen (beginnent mit ^) interpretiert * keine Command-Substitution ausgeführt $HOME den Inhalt der Shell-Variablen HOME und '$HOME' den String $HOME. Externen Kommandos werden alle übergebenen Flags und Parameter als Kommandozeile übergeben. Alle exportierten Shell-Variablen werden den externen Kommandos im Environment übergeben. Das Betriebssystem limitiert die Länge der Kommandozeile auf maximal 125 Zeichen. Die Übergabe von mehr Zeichen ist durch das xArg-Protokoll möglich. Die Flags der internen Kommandos werden i.d.R. durch ein Minuszeichen eingeleitet. Näheres siehe commands.doc. Die Shell benutzt eine Reihe eigener Flags, die mit dem internen Kom- mando set eingestellt werden können. Siehe hierzu commands.doc. ---------------------------------------------------------------------------- VERKETTETE KOMMANDOS Kommandos können in einer Zeile durch Semikolon getrennt angeführt werden. Die Kommandos werden von links nach rechts ausgeführt. Wenn eine eingegebene Zeile mit einem Dach (^) endet, wird anstelle des Daches die Fortsetzung der Zeile von der Sekundäreingabe eingelesen. Das entspricht dem Backslash in Unix. (In TOS ist der Backslash zum Trennen von Datei- und Ordnernamen reserviert.) Beispiel: ec^ ho ha^ l^ lo entspricht "echo hallo". Dabei kann diese Eingabe sowohl von der Tastatur als auch aus einem Shellscript oder einer Shellfunktion stammen. ---------------------------------------------------------------------------- SHELLVARIABLEN Eine besondere Art von internem Kommando ist die Zuweisung eines Wertes an eine Shellvariable. Alle Shellvariablen sind Stringvariablen. Der Name einer Shellvariablen kann in beliebiger Reihenfolge Buchstaben, Ziffern und Underscores (_) enthalten. Es können bis zu 200 Variablen angelegt werden; wer damit nicht auskommt, benutze den Software-Support, um eine Version der Shell mit größeren Kapazitäten zu erhalten. Die Maximalanzahl der Variablen einer Shell kann mit "ver -l" ermittelt werden. Jede Shell-Variable hat einen Status, der aus beliebigen (auch null) der folgenden Eigenschaften besteht: USR (User) Die Variable wurde vom Benutzer angelegt oder verändert. SYS (System) Es handelt sich um eine Systemvariable, die von der Shell verwaltet wird. Hierzu gehören z.B. die Positionsparameter $0, $1..., $#, $? usw. R/O (Read-Only) Der Wert der Variablen darf nicht verändert und die Variable darf nicht gelöscht werden. EXP (Exportiert) Die Variable befindet sich im Environment. Die Eigenschaften USR und SYS können nicht beeinflußt werden. Die Eigenschaften R/O und EXP können mit den Kommandos `readonly' und `export' gesetzt und gelöscht werden. Siehe hierzu commands.doc. DEKLARATION Shell-Variablen brauchen nicht deklariert zu werden. ZUWEISUNG Die Zuweisung eines Wertes an eine Shell-Variable geschieht durch eine Eingabe der Form Variable=Wert z.B.: NAME=Okami-Shell Es wird der String "Okami-Shell" der Shellvariablen NAME zugewiesen. In Unix ist es üblich, Shell-Variablen in Großbuchstaben zu schreiben, es sind allerdings auch Kleinbuchstaben möglich. NAME und Name sind zwei unterschiedliche Variablen. Auf die folgende Weise kann einer Variablen ein leerer Wert zugewiesen werden: Variable="" Der Wert der Variablen wird also gelöscht, aber die Variable selber bleibt bestehen. Außerdem können die internes Kommandos "read", "fsel", "alert" und "mouse" zur Zuweisung von Eingaben an Shellvariablen benutzt werden. Siehe hierzu commands.doc. BENUTZUNG Der Wert einer Shell-Variablen kann durch Angabe des Variablennamens mit vorgestelltem Dollar-Zeichen angegeben werden. In einer Eingabezeile der Shell werden erst alle Variablen zu den betreffenden Werten expandiert, bevor die Zeile ausgeführt wird. Shell-Variablen, an die noch kein Wert zugewiesen wurde, werden als Leerstrings behandelt. Beispiele: NAME=Okami-Shell echo $NAME erzeugt die Ausgabe "Okami-Shell". NAME=Okami-Shell echo Der Name ist $NAME und nicht anders. erzeugt die Ausgabe "Der Name ist Okami-Shell und nicht anders." VAR1=$VAR2 weist der Variablen VAR1 den Wert der Variablen VAR2 zu. VAR1=VAR2 VAR3=VAR1 $VAR1=$VAR3 weist der Variablen VAR2 den String VAR1 zu (sic). Es ist auch möglich, Shell-Kommandos an Variablen zuzuweisen und dann ausführen zu lassen: CC=c:\compiler\cc.ttp $CC test.c ruft das Programm c:\compiler\cc.ttp mit dem Parameter test.c auf. LÖSCHEN Auf die folgende Weise werden Variablen gelöscht: Variable= Dies ist nicht zu verwechseln mit dem Löschen des Inhalts einer Variablen (siehe oben). Wenn hinter dem Gleichheitszeichen nichts steht, wird die Variable vollständig gelöscht und belegt danach keinen Platz mehr in der Variablentabelle. Dies ist notwendig, da die Shell nur über eine begrenzte Anzahl von Variablen verfügt. Besonders Shell-Scripts, die Variablen für lokale Zwecke benutzen, sollten diese Variablen nach der Benutzung wieder freigeben. Shellvariablen können außerdem mit dem Kommando unset gelöscht werden. Beim Löschen verliert die Variable natürlich auch ihren Status. Um den Status zu erhalten, darf nur der Wert der Variablen gelöscht werden (NAME=""). Beispiele: NAME= Die Shell-Variable NAME wird gelöscht. unset NAME Ebenso. SAVECWD=$CWD cd c:\work\test .......................(weitere Kommandos) cd $SAVECWD Das aktuelle Verzeichnis (das stets in der Variablen CWD steht) wird in der Variablen SAVECWD gesichert. Danach wird das aktuelle Verzeichnis geändert (mit dem internen Kommando "cd"), und es werden weitere Kommandos ausgeführt. Anschließend wird das aktuelle Verzeichnis wieder restauriert. Diese Technik sollte von allen Shellscripts benutzt werden, die das aktuelle Verzeichnis ändern. Unter Unix werden Shellscripts stets von Subshells ausgeführt, und das aktuelle Verzeichnis ist eine Eigenschaft eines Prozesses, weswegen Shellscripts das aktuelle Verzeichnis ändern können, ohne das aktuelle Verzeichnis der aufrufenden Shell zu beeinflussen. Die Okami-Shell benutzt keine Subshells, und daher kann jedes Shell script das aktuelle Verzeichnis der Shell ändern, was in der praktischen Anwendung nicht immer erwünscht ist. Das umständliche Speichern und Restaurieren des aktuellen Verzeichnisses entfällt, wenn die Shell-Flags x und c gesetzt sind. Siehe hierzu das interne Kommando `set' in commands.doc. SYSTEMVARIABLEN Eine Reihe von Shellvariablen werden von der Shell selber angelegt und benutzt. Es ist teilweise möglich, die Werte dieser Variablen zu verän- dern. Diese sind: OKSH_PROFILE Das beim Start der Shell zu landende Profile. Muß folglich bereits beim Start der Shell im Environment vorhanden sein und hat von da an keine Bedeutung für die Shell mehr. PS1 Das Eingabeprompt. Kann vom Anwender verändert werden (was normalerweise im Profile geschieht). Der Defaultwert ist " $ ". PS2 Das sekundäre Eingabeprompt. Erscheint z.B. bei der Eingabe von Shellfunktionen. Kann beliebig verändert werden, der Defaultwert ist "> ". OKAMISHELL Die Versionsnummer der Shell. Kann nicht verändert werden. Diese Variable wird nicht an gestartete Programme weitergegeben und ist deshalb nur in Shellscripts gesetzt, wenn diese unter der Okami-Shell laufen. Daher kann das Vorhandensein dieser Variablen als Test benutzt werden, ob ein Shellscript unter der Okami- oder einer anderen Shell ausgeführt wird. TERM Der Rechnertyp, wird anhand des _MCH-Cookies eingestellt und ist je nachdem "Atari ST", "Atari Mega ST", "Atari STE" oder "Atari TT". Wenn kein Cookie-Jar installiert ist, wenn kein _MCH-Cookie vorhanden ist oder wenn dessen Wert kleiner als 0 oder größer als 3 ist, wird "Atari ST" benutzt. TERM ist in der jetzigen Version der Shell noch ohne weitere Bedeutung, wird aber von einigen Program- men benutzt, die eine Unix-ähnliche Termcap verwenden (z.B. Gnu-Emacs) und sollte dann auf den entsprechenden, von der Termcap benötigten Wert (z.B. "st" oder "vt52") eingestellt werden. CWD Das aktuelle Verzeichnis. Wird nach jedem Wechsel des Verzeichnisses automatisch aktualisiert und sollte nicht von Hand verändert werden. (Durch eine Zuweisung an diese Variable wird das aktuelle Verzeichnis nicht geändert.) HOME Das Verzeichnis, aus dem die Shell gestartet wurde (genauer gesagt das aktuelle Verzeichnis zum Zeitpunkt des Starts der Shell). Kann nach Bedarf verändert werden. ETC Das Verzeichnis, in dem die Shell Hilfsdateien wie z.B. die Textdatei für das help-Kommando erwartet. Wird bei Programmstart auf denselben Wert wie HOME eingestellt und kann beliebig verändert werden. SHELL Hier soll der vollständige Aufrufpfad des Shellprogramms eingetragen sein. Da die Shell diesen nicht mit völliger Sicherheit selber bestimmen kann, wird hier $HOME\sh.ttp eingetragen. Kann beliebig angepaßt werden, wenn diese Angabe einmal nicht zutrifft. Wird nicht von der Shell, aber von einigen Programmen benutzt (z.B. Micro-Emacs oder Pure C). Wer ein neues Programm schreibt, sollte die Shell lieber über den _shell_p-Zeiger aufrufen. PAGELEN Die Anzahl der Zeilen auf dem Bildschirm. Wird von dem internen Kommando pg (bzw. more) benutzt. Kann beliebig eingestellt werden. Die Defaulteinstellung ist 23. PIPDIR Das Laufwerk und der Pfad, auf dem die Hilfsdateien von Pipelining, Command Substitution usw. erzeugt werden. Muß auf einem beschreibbaren Laufwerk (am besten auf einer Ramdisk) liegen. Die Defaulteinstellung ist $HOME. Kann beliebig verändert werden. NULL Der Name des Gerätes oder der Datei, an die die Ausgaben geleitet werden, die zum Null-Gerät (NULL:) umgeleitet werden. Kann verändert werden. Die Defaulteinstellung ist "PRN:" (paralelle Schnittstelle) oder "u:\dev\null", wenn MiNT installiert ist. Wer MiNT nicht benutzt und einen Drucker hat, sollte hier eine Datei z.B. auf der Ramdisk eintragen. Die Einstellung AUX: für die serielle Schnittstelle ist nicht möglich, da diese Schnittstelle von der Standard-Fehlerausgabe belegt ist. (Und was lernen wir daraus? So schnell wie möglich MiNT installieren.) PATHSEP Die Zeichen, die als Trennzeichen in den Variablen PATH, XEXT usw. gelten sollen. Die Voreinstellung ist ",;", was bedeutet, daß in PATH usw. einzelne Felder mit Kommata oder Semikolons getrennt werden können. Wenn in MiNT nur das unifizierte Dateisystem auf Laufwerk U: benutzt, kann in PATHSEP auch den Doppelpunkt eintragen und die Felder in PATH wie in Unix mit Doppelpunkten trennen. XEXT Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten Extendern. Dateien mit einem der hier aufgeführten Extender können als Binärprogramme gestartet werden. Die Defaulteinstellung ist ".prg,.tos,.ttp,.app". Die Punkte vor den Extendern müssen mit angegeben werden. Kann beliebig verändert werden. SEXT Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten Extendern. Dateien mit einem der hier aufgeführten Extender können als Shellscripts gestartet werden. Die Defaulteinstellung ist ".sh". Die Punkte vor den Extendern müssen mit angegeben werden. Kann beliebig verändert werden. GEXT Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten Extendern. Binärdateien mit einem der hier aufgeführten Extender werden als GEM-Programme, d.h. nicht direkt, sondern über die Shellfunktion gemexec gestartet. Siehe hierzu den Abschnitt über gemexec in commands.doc. Die Defaulteinstellung ist ".prg". Kann beliebig verändert werden. Wie in commands.doc erklärt, müssen die Extender nicht unbedingt denen von ausführbaren Programmdateien entsprechen. MANEXT Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten Extendern. Dateien mit einem der hier angeführten Extender werden von der Online-Hilfe mit der Helptaste oder dem Kommando man als Anleitungsdateien erkannt. Die Voreinstellung lautet ".doc,.man". Kann beliebig verändert werden. PATH Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten Pfaden. Bei der Eingabe eines externen Kommandos ohne vollständige Pfadangabe wird die Datei auf den hier angegebenen Pfaden gesucht. Die Defaulteinstellung ist ".,..,$HOME,$HOME\bin". Kann beliebg verändert werden. CDPATH Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten Pfaden. Beim Wechsel des aktuellen Arbeitsverzeichnisses mit "cd" wird, wenn der bei cd angegebene Pfad nicht existiert und nicht absolut angegeben ist, auf den in CDPATH gespeicherten Pfaden gesucht. Die Defaulteinstellung ist "..,\". Kann beliebig verändert werden. MANPATH Eine Liste von durch die in $PATHSEP angeführten Zeichen getrennten Pfaden. Auf diesen Pfaden sucht die Online-Hilfe (Helptaste oder das Kommando `man') nach Anleitungsdateien. Die Defaulteinstellung ist "$HOME\doc". Kann beliebig verändert werden. HELPFILE Der Name der Datei, aus der die Erklärungen, die bei Druck auf die Help-Taste ausgegeben werden, stehen. Die Default einstellung ist "$HOME\doc\commands.doc". Kann beliebig verändert werden. CLIPDIR Enthält den Pfad des GEM-Clipboards. Wird durch die Kommandos gon und clipb initalisiert, die Voreinstellung bei Programmstart lautet "X:\scrapdir\scrap.*", wobei X: das Bootlaufwerk ist. Diese Variable sollte nur mit dem Kommando clipb verändert werden. Siehe hierzu auch commands.doc. Enthält bei Eingabe eines Kommandos den Namen des Kommandos und beim automatischen Aufruf der Funktion gemexec den vollständigen Pfad des aufzurufenden Programms. 1 Enthält den ersten Parameter der Eingabezeile. 2 Enthält den zweiten Parameter der Eingabezeile usw. # Enthält die Anzahl der Parameter der Eingabezeile. * Enthält die vollständige Eingabezeile. ? Enthält den Rückgabewert des zuletzt ausgeführten Kommandos. Die folgenden Shellvariablen werden nur von einzelnen internen Kommandos benutzt. COLUMNS von `scr': Anzahl der Zeilen auf dem Bildschirm. DIALPREFIX für `dial': Präfix des Modem-Wählkommandos. Nach dem Start der Shell werden Variablendefinitionen aus dem Environment gelesen und ausgeführt. Auf diese Weise können alle Variablen (auch LOGNAME usw.) geändert, aber keine gelöscht werden. ---------------------------------------------------------------------------- EIN/AUSGABE-UMLEITUNG 1) Für interne Kommandos Die Eingabe, Ausgabe und Fehlerausgabe jedes internen Kommandos kann auf einfache Weise in bzw. aus einer beliebigen Datei oder zu bzw. von einem Gerät umgeleitet werden. Folgende Umleitungsmöglichkeiten stehen zur Verfügung: <Datei Umleitung der Eingabe >Datei Umleitung der Ausgabe, die Datei wird vorher gelöscht >>Datei Umleitung der Ausgabe, sie wird an die Datei angehängt 2>Datei Umleitung der Fehlerausgabe, die Datei wird vorher gelöscht 2>>Datei Anhängen der Fehlerausgabe an die Datei Anstelle von "Datei" können auch die folgenden Geräte angegeben sein: CON: Konsole (Default) PRN: parallele Schnittstelle (Drucker) AUX: serielle RS232-Schnittstelle (Modem) NULL: ignorieren Das Gerät NULL:, auch Null-Gerät genannt (in Unix: /dev/null), wird nicht vom Betriebssystem des ST unterstützt, sondern von der Shell simuliert. Der Zweck eines Null-Gerätes ist, die Ausgabe oder Fehlerausgabe eines Kommandos zu unterdrücken. Die Shell-Variable NULL gibt an, wo die Ausgabe, die an NULL: umgeleitet wird, tatsächlich landen soll. Normalerweise ist das die Druckerschnittstelle; wenn diese von einem Drucker belegt ist, sollte man eine reguläre Datei z.B. auf der Ramdisk angeben (NULL=G:/null). Wer MiNT benutzt, hat damit keine Probleme, da MiNT ein Null-Gerät zur Verfügung stellt. Unter MiNT sollte man NULL auso auf u:/dev/null einstellen (was die Shell beim Starten automatisch tut). Beispiel: rm *.dup löscht sämtliche dup-Dateien, gibt aber eine Fehlermeldung aus, wenn keine solchen Dateien vorhanden sind oder wenn sie schreibgeschützt sind. Um die Fehlermeldung zu unterdrücken, kann man stattdessen schreiben: rm *.dup 2>NULL: Dadurch werden die Fehlermeldungen an das Null-Gerät geleitet. (Nebenbei: bei Verwendung von rm -f *.dup werden auch keine Fehlermeldungen ausgegeben, allerdings werden damit auch schreibgeschützte Dateien gelöscht.) Wenn keine Umleitung angegeben ist, geht die Eingabe von der Tastatur und die Ausgabe und Fehlerausgabe zum Bildschirm, genauer gesagt zu der Standard-Ein- und -Ausgabe der Shell selber (die beim Start von sh.ttp angegeben werden kann). PIPELINING Die Idee des Pipelining ist es, die Ausgabe eines Kommandos zur Eingabe des nächsten zu machen. So schreibt z.B. das memex-Kommando einen Speicherbereich auf seine Ausgabe, und das hd-Kommando fertigt von seiner Eingabe ein Hexdump an. Mit dem Pipelining können beide Kommandos verbunden werden, d.h. man bekommt ein Hexdump eines Speicherauszuges. Um zwei Kommandos in einer Pipeline zu verbinden, wird zwischen sie ein senkrechter Strich (|), auch Pipe genannt, gesetzt, z.B.: hd sh.ttp | pg Die Ausgabe des hd-Kommandos (ein langer Hexdump) wird zur Eingabe des pg-Kommandos, wodurch der Hexdump seitenweise angezeigt wird. Die Schreibweise a | b ist äquivalent zu: (a und b sind beliebige Kommandos incl. ihren Parametern) TMP=$PIPDIR\pip$$ a > $TMP chmod +h $TMP b < $TMP rm $TMP unset TMP (mit drei kleinen Unterschieden: 1. zum Bilden eines eindeutigen Dateinamens wird nicht $$, sondern ein anderer Zähler benutzt, 2. die Datei wird nach dem Anlegen und nicht erst nach dem Ende von a unsichtbar gemacht und 3. es wird keine Shellvariable benutzt.) Dies ist ein wesentlicher Unterschied zu Unix, wo alle an einer Pipe beteiligten Kommandos (Prozesse) gleichzeitig laufen. Eine Pipeline ist unter Unix eine Einrichtung des Betriebssystems, die von der Okami-Shell nur simuliert wird. (Wie gesagt, Okami ist eine Shell und kein Betriebssystem.) Das Laufwerk und der Ordner, auf dem die Pipe-Dateien erzeugt werden, kann mit der Shellvariablen PIPDIR eingestellt werden. Die Defaulteinstellung beim Start der Shell ist $HOME. Dadurch bietet sich die Möglichkeit, die Pipe-Dateien auf ein schnelles Laufwerk zu legen, z.B. auf eine Ramdisk oder eine wenig benutzte Partition der Festplatte. VORSICHT: Wenn $PIPDIR auf einen nicht existierenden Ordner oder Laufwerk eingestellt ist, erscheinen anstelle von Pipe-Operationen nur Fehlermeldungen der Form: Error: cannot open .....\pip3 (Anstelle von ...... steht der Inhalt von PIPDIR.) In diesem Fall wird keins der an einer Pipe beteiligten Kommandos ausgeführt. Abhilfe schafft das Kommando mkdir -r $PIPDIR/ im Profile nach dem Einstellen von PIPDIR. Dadurch werden alle zu $PIPDIR gehörenden Unterverzeichnisse erzeugt. Die Pipe-Datei kann mit folgendem Kommando sichtbar gemacht werden: ls -a $PIPDIR\pip* | cat INLINE-DOKUMENTE Als Inline- oder Hier-Dokument wird eine spezielle Art der Eingabeumleitung bezeichnet, bei der die einem Kommando zuzuführende Eingabe direkt von der Eingabe oder z.B. dem Shellscript stammt. Beispiel: cat <<eof Das ist ein Text, der zu der Eingabe des cat- Kommandos wird. eof Diese Zeilen können von der Tastatur eingegeben, aber auch in einem Shellscript oder einer Shellfunktion stehen. Die Shell betrachtet die Zeichenkette nach "<<" als Terminierungsstring und schreibt die nachfolgenden Zeilen in eine Datei, die dann als Eingabe des Kommandos benutzt wird. Das Inline-Dokument wird durch eine Zeile beendet, die nur (bis auf führende Leerzeichen) aus dem Terminierungsstring besteht. Wenn den << direkt ein Minuszeichen folgt, also z.B. cat <<-eof , werden alle führenden Leerzeichen der Eingabezeilen entfernt. Das Minuszeichen gehört nicht zu dem Terminierungsstring. Die Shell führt auf allen eingelesenen Zeilen Variablensubstitutionen und Command Substitution aus. Inline-Dokumente sind sinnvoll in Shellscripts, die mehrzeilige Ausgaben erzeugen sollen, wodurch sich Reihen von echo-Kommandos vermeiden lassen. 2) Für externe Kommandos Theoretisch funktionieren sämtliche Ein/Ausgabe-Umleitungen inklusive der Pipeline auch mit externen Kommandos. In der Praxis jedoch erlauben nicht alle Programme diese Möglichkeit, z.B weil sie Tastatur und Bildschirm direkt über die entsprechenden Bios-Funktionen (Bconout etc.) ansprechen, die sich nicht umleiten lassen. (Mit MiNT lassen sich auch solche Programme umleiten.) Die Okami-Shell leitet die Ein/Ausgabe auf Gemdos-Basis um, was bedeutet, daß alle Programme, die für die Ein/Ausgabe Gemdos-Funktionen (Cconout etc.) benutzen, umgeleitet werden können. C-Programme, die die Standard-Streams stdin und stdout benutzen, werden normalerweise korrekt umgeleitet. GEM-Programme sind von vornherein gegen jede Art der Umleitung immun, da sie den Bildschirm über den entsprechenden VDI-Gerätetreiber ansprechen. ---------------------------------------------------------------------------- COMMAND SUBSTITUTION Die Okami-Shell bietet die Möglichkeit, die Ausgabe eines Kommandos in eine Kommandozeile einzubauen. Möchte man z.B. eine Ausgabe wie "Es sind ... Bytes frei" erzeugen, in die die Anzahl der freien Bytes (die mit dem Kommando mem ermittelt werden kann) eingebaut sind, dann kann die Ausgabe von mem auf folgende Weise in das echo-Kommando eingebaut werden: echo Es sind `mem` Bytes frei. Alles, was in einer Eingabezeile zwischen zwei Accent grave (`) steht, wird als Kommando betrachtet und ausgeführt. Die Ausgabe wird anstelle der in Accent grave stehenden Zeichenkette in die Eingabezeile eingesetzt. Dieses Verfahren wird als Command Substitution bezeichnet. Wenn die Ausgabe des Kommandos über mehrere Zeilen geht, wird nur die erste Zeile (also die Ausgabe bis zum ersten Zeilenende) benutzt. Als Zwischenspeicher für die Ausgabe des Kommandos wird eine Datei namens $PIPDIR/csubXXXX benutzt. XXXX ist hierbei eine laufende Nummer, und $PIPDIR ist das Laufwerk, über das auch die Pipelining- Operationen laufen. Diese Datei wird nach Verwendung gelöscht. Beispiele: Speichern der Shellflags: SET=`set -` Wiederherstellen mit: set $SET Anzeigen einer Datei, die in demselben Ordner liegt wie $FILE1, die aber denselben Basisnamen wie $FILE2 hat: cat `dirname $FILE1`/`basename $FILE2` Löschen der ältesten Datei mit Nachfrage: rm -i `ls -t` ---------------------------------------------------------------------------- ENVIRONMENT Die Okami-Shell bietet die Möglichkeit, Definitionen von Shell-Variablen in das Environment zu übernehmen. Diese Definitionen werden dann allen gestarteten Programmen übergeben. Mit dem internen Kommando export können beliebige Shellvariablen in das Environment ausgenommen oder daraus entfernt werden. In der Basepage eines Programms steht ab Offset 0x2c die Adresse des Environment-Strings. Diese Adresse wird berechnet als: char *BaseAdr; char *EnvAdr; EnvAdr = *(char **)(BaseAdr+0x2c); BaseAdr ist die Adresse der Basepage (wird irgendwie vom Compiler zur Verfügung gestellt). EnvAdr ist dann die Adresse des Environment-Strings. Dieser String hat folgende Syntax: EnvString ::= { VarDefinition } "\0" VarDefinition ::= VarName "=" VarWert "\0" Beispiel: "a=Variable a\0b=Variable b\0usw=undsoweiter\0\0" Es werden folgende Variablen gesetzt: a auf "Variable a" b auf "Variable b" usw auf "undsoweiter" ---------------------------------------------------------------------------- MINT-UNTERSTÜTZUNG Die Okami-Shell benutzt und unterstützt MiNT, das Multitasking-Betriebssystem für TOS-Rechner. Wenn MiNT installiert ist, dann: * meldet die Shell sich als MiNT-Domain-Prozess an. * wird die Shellvariable NULL als u:/dev/null voreingestellt. * wird die MiNT-Signalverarbeitung verwendet. Es können dann interne Kommandos mit Ctrl-C abgebrochen werden. Mit Ctrl-\ wird die Shell abgebrochen. * können mit `&' Hintergrundprozesse gestartet werden. * wird die Tastatureingabe des Zeileneditors mit Fselect abgewicklt, d.h. die Shell benötigt während der Eingabe praktisch keine CPU-Zeit. * liefert das Kommando `ps' eine formatierte Ausgabe der Dateien in u:/proc. * liefert das Kommando `time' zusätzlich User- und Kernalzeiten. * benutzt das Kommando `sleep' keine Warteschleife, sondern Systemaufrufe, um während des Wartens keine CPU-Zeit zu benötigen. * beendet das Kommando `shutdown' alle Prozesse, bevor es das System abschaltbereit erklärt. * kann mit dem Kommando `ver -m' die Versionsnummer des installierten MiNT ermittelt werden. * sind die folgenden Kommandos und Optionen nutzbar: id User- und Gruppennummer ermitteln kill Signale an Prozesse senden ln Links erzeugen ls -s symbolische Links anzeigen tty Terminalnamen ermitteln ---------------------------------------------------------------------------- GRÜSSE 1) An die Firma GRP in Aachen, für lebenswichtige Kenntnisse in C und Unix. 2) Für die Begleitung in zahllosen Stunden voller Lust und Frust vor der flimmerfreien Flimmerkiste: Mike Oldfield, The Beatles, Little Richard, Bill Haley, Tommy Roe, Lesley Gore, Pat Boone, Elvis Presley, Chuck Berry, Del Shannon, Chris Montez, Billy Joe Royal, The Box Tops, The Cascades, Trini Lopez, Chris Andrews, Mary Hopkins, The Tremoloes, Bobby Vee, The Kinks, The Turtles, The Swinging Blue Jeans, Shane Fenton & The Fentones, The Piltdown Men, Helen Shapiro, Cliff Richard, The Cowsills, Jerry Lee Lewis, Melanie, Buddy Hollie, The Lovin' Spoonful, The Crystals, The Knickerbockers, The Crests, Every Mother's Son, The Shangri Las, Bernard Cribbins, The Shadows, Frank Ilfield u.v.a. Atari ST, GEM, Unix, MS-Dumpf usw. sind eingetragene Warenzeichen von - ach das wißt Ihr schon? Na gut. Diese Anleitung wurde ursprünglich als reine Ascii-Datei geschrieben, dann in eine Tempus-Word-Datei umgeformt und wegen der absoluten Unfähigkeit von Tempus Word, Texte vernünftig formatiert als Ascii-Datei auszugeben, in nroff umgeschrieben und mit "miniroff" formatiert.